home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group93a.txt
/
000029_icon-group-sender _Mon Jan 18 08:43:05 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-04-21
|
5KB
Received: by cheltenham.cs.arizona.edu; Mon, 18 Jan 1993 11:23:36 MST
Message-Id: <9301181543.AA01233@turing.cse.nau.edu>
From: sbw@turing.cse.nau.edu (Steve Wampler)
Date: Mon, 18 Jan 1993 08:43:05 MST
In-Reply-To: Michael Sperber's mail message of Jan 18, 1:52pm.
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: sperber@soir.informatik.uni-tuebingen.de (Michael Sperber)
Subject: Re: Pattern matching in Icon?
Cc: icon-group@cs.arizona.edu
Status: R
Errors-To: icon-group-errors@cs.arizona.edu
On Jan 18 at 1:52pm, Michael Sperber writes:
}
} Well, at least one person got it (partially) right. I had't
} thought of Prolog as the inspiration for the control structure
} I had proposes, but in fact, a unification is what would happen
} in pattern matching, albeit in a much more limited sense, that
} is also easier and more straightforward to implement.
} As I keep saying (jeez, has NOONE here ever looked at Hope, Miranda,
} ML or the like?!), the proposed scheme could be used to
} implement structural recursion VERY elegantly - with the
} added power of generators.
But - you seem to be saying that the language designer is going to
implement *exactly* the pattern matching facility you want in
*exactly* the right way - once you add something like that to
a language, it's *very* hard to change! What I'm saying is
that Icon already has a facility that can not only do everything
you want, with really very little effort (you write your pattern-matching
functions once) but it also has *the ability to be extended* as you,
the programmer, sees fit.
Furthermore, your proposed pattern matching construct violates
syntactic consistency - it looks like something else (witness the
confusion those of us who have used Icon extensively have with
'seeing' what it is you want) - normal Icon exprssions. It also
changes the structure of the language so that there are places where
arbitrary expressions are allowed and not patterns, and places where
patterns are allowed and not arbitrary expressions (with very little
syntactic clues as to what is needed where!).
Finally, you're introducing a 'sublanguage' into Icon (just as the
pattern matching of SNOBOL was a sublanguage to SNOBOL). Icon is
already a fairly complex language, I'm not convinced that adding
syntax to support a fairly limited operation is worth it, *especially*
given that Icon already has a more powerful capability with its
case expression.
} Steve Wampler proposed ...
}
} >I guess the only real debate is whether to add it into the language
} >or not:
} >
} > case s := <expression> of {
} > match_syntax_tree(s,"let") : {a := s.arguments
} > ...
} > }
} >
} > ...
} >
} > procedure match_syntax_tree(s, op)
} ># match a pattern, in this case, the pattern is simple...
} > if type(s) == "syntax_tree" & s.operator == "let" then
} > return s
} > end
} >
} >not as visually pleasing as a new syntax would be, but I contend
} >this would be more flexible and generalizes better than fixed
} >patterns would...
}
} This stuff looks extremely awkward to me, in fact even more awkward
You find adding two assignment operators to your original syntax
'extremely' awkward? Why? More awkward, yes. But I don't see
that as 'extremely'! Or is that you're writing your own pattern
matching function(s) that you see as awkward? Again, you write them
once, hide them away in a library, and presto, no difference there
with having them built into the language -- except that you can
*change* them!
} than doing the pattern matching explicitly. It would mean having
} separate procedures (with different names, too!) for each constructor
} AND combination of constants/unknowns. My proposal was exactly
Nonsense. I named it 'match_syntax_tree'. You could just as easily
call it 'pat_match', or whatever, and implement an entire pattern matcher
in the one procedure. Yes, you have to *write* the procedure
to do what you want, but as I said, I consider that flexibility a net
win (in fact, personally, I find it a *huge* win - I *like* being able
to describe *exactly* what I want!) And you only have to write it *once*,
anyway... Plus you can have different pattern-matchers for different
contexts!
} aimed at removing that syntactic clumsiness. As I said (again,
} and again), that's exactly why compilers are so much easier to
} write and read in functional languages. The way to go would
} probably be using the variant translator feature of Icon to do
} the job. Anyone interested? (If I'm not all alone with this, I
} might actually get around to doing it, some day ...)
Now that I can see, particularly as an experiment - you could get the
syntax you want that way, and Icon already has the capability semantically.
The current syntax just doesn't bother me enough to justify my time on
it though. You'll still have to write the 'awkward' procedures for
actually doing the pattern matching, of course.
} Cheers :-> Chipsy
--
Steve Wampler
{....!arizona!naucse!sbw}
{sbw@turing.cse.nau.edu}